The present invention relates to the field of communications across a network adaptor boundaries and, more particularly, to dynamically calculating an inbound blocking factor using operating-system-level conditions.
Computers utilize network adaptors to physically and logically connect a computer to a network. A typical network adaptor includes microcode, embedded in firmware. A network adaptor can be implemented as a network interface card (NIC), can be an embedded component of a motherboard, or can be otherwise positioned. Hardware of the network adaptor is configured to perform physical layer functions (e.g., layer one of the Open Systems Interconnection Basic Reference (OSI) model). The microcode of the network adaptor is configured to direct components of the adaptor to perform Media Access Control (MAC) sublayer functions, where the MAC sublayer is the lower sublayer of the Data Link Layer (DLL), which is the second layer of the OSI model. The MAC sublayer is responsible for data encapsulation functions including frame assembly and parsing. Additionally, The MAC sublayer is responsible for media access control including initiation of frame transmissions and recovery of the same. A network adaptor typically has an associated network adaptor driver, which is a software interface between an operating system and the network interface adaptor. The adaptor driver typically performs Logical Link Control (LLC) functions, where the LLC is the upper sublayer of the DLL.
Applications typically only deal with the topmost layers of the OSI models. Additionally, the operating system or platform often has two well defined software interfaces for network communications; one between the media and transport layers and one between the transport layers and applications. The media-to-transport interface can be an adaptor driver, which is typically implemented as a driver conforming to the Network Driver Interface Specification (NDIS) or the Open Data-Link Interface (ODI). The application-to-transport interface defines a manner in which application programs can make use of the transport layers. For example, the application-to-transport interface layer can define how a Web browser communicates with TCP/IP transport software.
In current host to network adaptor communication interfaces, blocking of messages occurs. When multiple messages are blocked, they are combined into a single larger message, which is conveyed across the adaptor interface boundary. Inbound (from adaptor to host) messages can be queued in a network card memory during an inbound blocking stage, where they are conveyed from this queue across the adaptor interface boundary to a memory of the host, where they become available (visible) to the operating system of the host. Outbound (from host to adaptor) messages can be cached in a host memory during an outbound blocking stage before these messages are conveyed to remotely located devices. Optimal blocking of messages across the adaptor interface boundary can depend upon current state information of the host and of the network adaptor. Different blocking factors can exist for inbound messages and for outbound messages.
There are many well known packing algorithms and strategies, a majority of which dynamically calculate a blocking factor, which defines a quantity of messages to be queued or cached before messages are to be conveyed across the adaptor boundary. Conventional approaches for calculating a blocking factor are based upon state information from a single direction only. That is, a blocking factor for outbound messages (from host to adaptor) is based exclusively upon operating-system-level conditions (relating to operating system state). The blocking factor for inbound messages (from adaptor to host) is based exclusively upon adaptor-level conditions (relating to an adapter state).
This approach makes some logical sense when considering the OSI model, the various layers of abstraction in existence, and the information generally available to an algorithm calculating the blocking factor, which varies depending upon which OSI level at which the algorithm executes. More specifically, the inbound blocking factor is typically calculated by microcode associated with the network adaptor executing within network adapter hardware. Thus, only dynamic link layer (DLL) or adaptor-level information (adapter state information) is by default “visible” or available to the process determining the inbound blocking factor. Similarly, the outbound blocking factor is typically calculated by operating-system-level code, which has access to operating-system-level conditions (OS state information).
Basing blocking factor calculations upon state information from a single direction, however, only considers resources that are visible from that direction. Message transfer rates for each direction can be affected by state information of the other direction. For example, a low inbound blocking factor (currently based exclusively on adaptor state information) increases CPU utilization of a host (an operating-system-level resource). A high setting for an inbound blocking factor can increase network latency. No conventional algorithm or methodology exists for dynamically calculating an inbound blocking factor that uses operating-system-level conditions (OS state information) as an algorithm variable.